Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.541

Text File | 1996-02-12 | 27.6 KB | 842 lines

Frequently Asked Questions (FAQS);faqs.541



Archive-name: unix-faq/shell/csh-whynot
Version: $Id: csh-faq,v 1.2 92/11/30 05:26:37 tchrist Exp Locker: tchrist $

The following periodic article answers in excruciating detail
the frequently asked question "Why shouldn't I program in csh?".
It is available for anon FTP from convex.com in /pub/csh.whynot .


           Csh Programming Considered Harmful

Resolved: The csh is a tool utterly inadequate for programming, and
its use for such purposes should be strictly banned.

I am continually shocked and dismayed to see people write test cases,
install scripts, and other random hackery using the csh.  Lack of
proficiency in the Bourne shell has been known to cause errors in /etc/rc
and .cronrc files, which is a problem, because you *must* write these files
in that language.

The csh is seductive because the conditionals are more C-like, so the path
of least resistance if chosen and a csh script is written.  Sadly, this is
a lost cause, and the programmer seldom even realizes it, even when they
find that many simple things they wish to do range from cumbersome to
impossible in the csh.


FILE DESCRIPTORS

The most common problem encountered in csh programming is that
you can't do file-descriptor manipulation.  All you are able to
do is redirect stdin, or stdout, or dup stderr into stdout.
Bourne-compatible shells offer you an abundance of more exotic
possibilities.

Writing Files

In the Bourne shell, you can open or dup random file descriptors.
For example,

    exec 2>errs.out

means that from then on, stderr goes into errs file.

Or what if you just want to throw away stderr and leave stdout
alone?    Pretty simple operation, eh?

    cmd 2>/dev/null

Works in the Bourne shell.  In the csh, you can only make a pitiful
attempt like this:

    (cmd > /dev/tty) >& /dev/null

But who said that stdout was my tty?  So it's wrong.  This simple
operation *CANNOT BE DONE* in the csh.


Along these same lines, you can't direct error messages in csh
scripts out stderr as is considered proper.  In Bourne shell, you
might say:

    echo "$0: cannot find $file" 1>&2

but in the csh, you can't redirect stdout out stderr, so you end
up doing something silly like this:

    sh -c 'echo "$0: cannot find $file" 1>&2'

Reading Files

In the csh, all you've got is $<, which reads a line from your tty.  What
if you've redirected stdin?  Tough noogies, you still get your tty, which
you really can't redirect.  Now, the read statement
in the Bourne shell allows you to read from stdin, which catches
redirection.  It also means that you can do things like this:

    exec 3<file1
    exec 4<file2

Now you can read from fd 3 and get lines from file1, or from file2 through
fd 4.   In modern, Bourne-like shells, this suffices:

    read some_var 0<&3
    read another_var 0<&4

Although in older ones where read only goes from 0, you trick it:

    exec 5<&0  # save old stdin
    exec 0<&3; read some_var
    exec 0<&4; read another_var
    exec 0<&5  # restore it


Closing FDs

In the Bourne shell, you can close file descriptors you don't
want open, like 2>&-, which isn't the same as redirecting it
to /dev/null.

More Elaborate Combinations

Maybe you want to pipe stderr to a command and leave stdout alone.
Not too hard an idea, right?  You can't do this in the csh as I
mentioned in 1a.  In a Bourne shell, you can do things like this:

    exec 3>&1; grep yyy xxx 2>&1 1>&3 3>&- | sed s/file/foobar/ 1>&2 3>&-
    grep: xxx: No such foobar or directory

Normal output would be unaffected.  The closes there were in case
something really cared about all its FDs.  We send stderr to sed,
and then put it back out 2.

Consider the pipeline:

    A | B | C

You want to know the status of C, well, that's easy: it's in $?, or
$status in csh.  But if you want it from A, you're out of luck -- if
you're in the csh, that is.  In the Bourne shell, you can get it, although
doing so is a bit tricky.  Here's something I had to do where I ran dd's
stderr into a grep -v pipe to get rid of the records in/out noise, but had
to return the dd's exit status, not the grep's:

    device=/dev/rmt8
    dd_noise='^[0-9]+\+[0-9]+ records (in|out)$'
    exec 3>&1
    status=`((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) |
        egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1`
    exit $status;



COMMAND ORTHOGONALITY

Built-ins

The csh is a horrid botch with its built-ins.  You can't put them
together in many reasonable way.   Even simple little things like this:

        % time | echo

which while nonsensical, shouldn't give me this message:

        Reset tty pgrp from 9341 to 26678

Others are more fun:

        % sleep 1 | while
        while: Too few arguments.
        [5] 9402
        % jobs
        [5]     9402 Done                 sleep |


Some can even hang your shell.  Try typing ^Z while you're sourcing
something, or redirecting a source command.  Just make sure you have
another window handy.  Or try

    % history | more

on some systems.

Flow control

You can't mix flow-control and commands, like this:

    who | while read line; do
    echo "gotta $line"
    done


You can't combine multiline constructs in a csh using semicolons.
There's no easy way to do this

    alias cmd 'if (foo) then bar; else snark; endif'




Stupid parsing bugs

Certain reasonable things just don't work, like this:

    % kill -1 `cat foo`
    `cat foo`: Ambiguous.

But this is ok:

    % /bin/kill -1 `cat foo`

If you have a stopped job:

    [2]     Stopped              rlogin globhost

You should be able to kill it with

    % kill %?glob
    kill: No match

but

    % fg %?glob

works.

White space can matter:

    if(expr)

may fail on some versions of csh, while

    if (expr)

works!



SIGNALS

In the csh, all you can do with signals is trap SIGINT.  In the Bourne
shell, you can trap any signal, or the end-of-program exit.    For example,
to blow away a tempfile on any of a variety of signals:

    $ trap 'rm -f /usr/adm/tmp/i$$ ;
        echo "ERROR: abnormal exit";
        exit' 1 2 3 15

    $ trap 'rm tmp.$$' 0   # on program exit



6.  QUOTING

You can't quote things reasonably in the csh:

    set foo = "Bill asked, \"How's tricks?\""

doesn't work.  This makes it really hard to construct strings with
mixed quotes in them.  In the Bourne shell, this works just fine.
In fact, so does this:

     cd /mnt; /usr/ucb/finger -m -s `ls \`u\``

Dollar signs cannot be escaped in double quotes in the csh.  Ug.

    set foo = "this is a \$dollar quoted and this is $HOME not quoted"
    dollar: Undefined variable.

You have to use backslashes for newlines, and it's just darn hard to
get them into strings sometimes.

    set foo = "this \
    and that";
    echo $foo
    this  and that
    echo "$foo"
    Unmatched ".

Say what?  You don't have these problems in the Bourne shell, where it's
just fine to write things like this:

    echo     'This is
         some text that contains
         several newlines.'


As distributed, quoting history references is a challenge.  Consider:

    % mail adec23!alberta!pixel.Convex.COM!tchrist
    alberta!pixel.Convex.COM!tchri: Event not found.


VARIABLE SYNTAX

There's this big difference between global (environment) and local
(shell) variables.  In csh, you use a totally different syntax
to set one from the other.

In Bourne shell, this
    VAR=foo cmds args
 is the same as
    (export VAR; VAR=foo; cmd args)
or csh's
    (setenv VAR;  cmd args)

You can't use :t, :h, etc on envariables.  Watch:
    echo Try testing with $SHELL:t

It's really nice to be able to say

    ${PAGER-more}
or
    FOO=${BAR:-${BAZ}}

to be able to run the user's PAGER if set, and more otherwise.
You can't do this in the csh.  It takes more verbiage.

You can't get the process number of the last background command from the
csh, something you might like to do if you're starting up several jobs in
the background.  In the Bourne shell, the pid of the last command put in
the background is available in $!.

The csh is also flaky about what it does when it imports an
environment variable into a local shell variable, as it does
with HOME, USER, PATH, and TERM.  Consider this:

    % setenv TERM '`/bin/ls -l / > /dev/tty`'
    % csh -f

And watch the fun!


EXPRESSION EVALUATION

Consider this statement in the csh:


    if ($?MANPAGER) setenv PAGER $MANPAGER


Despite your attempts to only set PAGER when you want
to, the csh aborts:

    MANPAGER: Undefined variable.

That's because it parses the whole line anyway AND EVALUATES IT!
You have to write this:

    if ($?MANPAGER) then
    setenv PAGER $MANPAGER
    endif

That's the same problem you have here:

    if ($?X && $X == 'foo') echo ok
    X: Undefined variable

This forces you to write a couple nested if statements.  This is highly
undesirable because it renders short-circuit booleans useless in
situations like these.  If the csh were the really C-like, you would
expect to be able to safely employ this kind of logic.  Consider the
common C construct:

    if (p && p->member)

Undefined variables are not fatal errors in the Bourne shell, so
this issue does not arise there.

While the csh does have built-in expression handling, it's not
what you might think.  In fact, it's space sensitive.  This is an
error

   @ a = 4/2

but this is ok

   @ a = 4 / 2


The ad hoc parsing csh employs fouls you up in other places
as well.  Consider:

    % alias foo 'echo hi' ; foo
    foo: Command not found.
    % foo
    hi


ERROR HANDLING

Wouldn't it be nice to know you had an error in your script before
you ran it?   That's what the -n flag is for: just check the syntax.
This is especially good to make sure seldom taken segments of code
code are correct.  Alas, the csh implementation of this doesn't work.
Consider this statement:

    exit (i)

Of course, they really meant

    exit (1)

or just

    exit 1

Either shell will complain about this.  But if you hide this in an if
clause, like so:

    #!/bin/csh -fn
    if (1) then
    exit (i)
    endif

The csh tells you there's nothing wrong with this script.  The equivalent
construct in the Bourne shell, on the other hand, tells you this:


    #!/bin/sh -n
    if (1) then
    exit (i)
    endif

    /tmp/x: syntax error at line 3: `(' unexpected



RANDOM BUGS

Here's one:

    fg %?string
    ^Z
    kill  %?string
    No match.

Huh? Here's another

    !%s%x%s

Coredump, or garbage.

If you have an alias with backquotes, and use that in backquotes in
another one, you get a coredump.

Try this:
    % repeat 3 echo "/vmu*"
    /vmu*
    /vmunix
    /vmunix
What???


Here's another one:

    % mkdir tst
    % cd tst
    % touch '[foo]bar'
    % foreach var ( * )
    > echo "File named $var"
    > end
    foreach: No match.


SUMMARY


While some vendors have fixed some of the csh's bugs (the tcsh also does
much better here), many have added new ones.  Most of its problems can
never be solved because they're not actually bugs per se, but rather the
direct consequences of braindead design decisions.  It's inherently flawed.

Do yourself a favor, and if you *have* to write a shell script, do it in the
Bourne shell.  It's on every UNIX system out there.  However, behavior
can vary.

There are other possibilities.

The Korn shell is the preferred programming shell by many sh addicts,
but it still suffers from inherent problems in the Bourne shell's design,
such as parsing and evaluation horrors.  The Korn shell or its
public-domain clones and supersets (like bash) aren't quite so ubiquitous
as sh, so it probably wouldn't be wise to write a sharchive in them that
you post to the net.  When 1003.2 becomes a real standard that companies
are forced to adhere to, then we'll be in much better shape.  Until
then, we'll be stuck with bug-incompatible versions of the sh lying about.

The Plan 9 shell, rc, is much cleaner in its parsing and evaluation; it is
not widely available, so you'd be sacrificing portability.  No vendor
is shipping it yet.

If you don't have to use a shell, but just want an interpreted language,
many other free possibilities present themselves, like Perl, REXX, TCL,
Scheme, or Python.  Of these, Perl is probably the most widely available
on UNIX (and many other) systems and certainly comes with the most
extensive UNIX interface.  Some vendors even ship it standard.

If you have a problem that would ordinarily use sed or awk or sh, but it
exceeds their capabilities or must run a little faster, and you don't want
to write the silly thing in C, then Perl may be for you.  You can get
at networking functions, binary data, and most ofthe C library. There
are also translators to turn your sed and awk scripts into Perl scripts,
as well as a symbolic debugger.  Tchrist's personal rule of thumb is
that if it's the size that fits in a Makefile, it gets written in the
Bourne shell, but anything bigger gets written in Perl.

See the comp.lang.{perl,rexx,tcl} newsgroups for details about these
languages (including FAQs), or David Muir Sharnoff's comparison of
freely available languages and tools in comp.lang.misc and news.answers.


--
    Tom Christiansen      [e-mail]      convex!tchrist

    "UNIX was not designed to stop you from doing stupid things, because
     that would also stop you from doing clever things." -- Doug Gwyn
Xref: bloom-picayune.mit.edu comp.unix.shell:8334 news.answers:4768
Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!usenet
From: [e-mail] (Ted M A Timar)
Newsgroups: comp.unix.shell,news.answers
Subject: Changes to "Welcome to comp.unix.shell" [Frequent posting]
Supersedes: <unix-faq/shell/[e-mail]>
Followup-To: comp.unix.questions
Date: 24 Dec 1992 06:02:21 GMT
Organization: Empress Software
Lines: 29
Approved: [e-mail]
Distribution: world
Expires: 21 Jan 1993 06:02:09 GMT
Message-ID: <unix-faq/shell/[e-mail]>
NNTP-Posting-Host: pit-manager.mit.edu
X-Last-Updated: 1992/12/09

Archive-name: unix-faq/shell/diff

*** /tmp/,RCSt1a18494    Fri Dec  4 07:52:28 1992
--- intro    Fri Dec  4 07:43:02 1992
***************
*** 2,12 ****
  Newsgroups: comp.unix.shell,news.answers
  Followup-To: comp.unix.shell
  Organization: Empress Software
! Subject: Welcome to comp.unix.shell [Biweekly posting]
  Approved: [e-mail]

! Archive-name: unix-faq/shell-intro
! Version: $Id: intro,v 2.0 92/10/20 12:08:24 tmatimar Exp $

  This article is a monthly attempt to remind potential posters about
  what is appropriate for comp.unix.shell.  If you would like to make
--- 2,12 ----
  Newsgroups: comp.unix.shell,news.answers
  Followup-To: comp.unix.shell
  Organization: Empress Software
! Subject: Welcome to comp.unix.shell [Frequent posting]
  Approved: [e-mail]

! Archive-name: unix-faq/shell/intro
! Version: $Id: intro,v 2.1 92/12/04 07:48:53 tmatimar Exp $

  This article is a monthly attempt to remind potential posters about
  what is appropriate for comp.unix.shell.  If you would like to make
Xref: bloom-picayune.mit.edu comp.unix.shell:8336 news.answers:4771
Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!usenet
From: [e-mail] (Ted M A Timar)
Newsgroups: comp.unix.shell,news.answers
Subject: Welcome to comp.unix.shell [Frequent posting]
Supersedes: <unix-faq/shell/[e-mail]>
Followup-To: comp.unix.shell
Date: 24 Dec 1992 06:02:44 GMT
Organization: Empress Software
Lines: 202
Approved: [e-mail]
Distribution: world
Expires: 21 Jan 1993 06:02:09 GMT
Message-ID: <unix-faq/shell/[e-mail]>
NNTP-Posting-Host: pit-manager.mit.edu
X-Last-Updated: 1992/12/09

Archive-name: unix-faq/shell/intro
Version: $Id: intro,v 2.1 92/12/04 07:48:53 tmatimar Exp $

This article is a monthly attempt to remind potential posters about
what is appropriate for comp.unix.shell.  If you would like to make
any suggestions about the content of this article, please contact
its maintainer at [e-mail].

Companion articles include the answers to some Frequently
Asked Questions.  You may save yourself a lot of time by reading
those articles before posting a question to the net.

If you have not already read the overall Usenet introductory material
posted to "news.announce.newusers", please do.  Much of this article
overlaps with the common sense guidelines posted there.

         Should I Post My Shell Question to the Net?

Often the answer is "No, you can get an answer a lot faster without
posting a question." Before you post, you should try -

    o Reading the manual for your system.  Some day you may encounter
      the phrase "RTFM", which stands for "Read the Fine Manual"
      (except 'F' doesn't really stand for "Fine").  If you ask
      someone a question and they tell you to RTFM, it's an
      indication that you haven't done your homework.  For instance,
      if you are trying to make a script run under csh instead of sh,
      check the man page for "csh".  It might tell you what you need
      to know.

      When people use terminology like "read(2)", they are referring
      to the "read" man page in section 2 of the manual (which you
      would see by using "man 2 read").

    o Finding a knowledgeable user at your site.  Many sites have
      at least a few shell experts who will be happy to help you
      figure out how to specify that a script should be run by csh.
      Many larger sites, particularly universities, may even have
      paid consultants whose job is to help you with these problems.
      Check with them first.

    o Find a good introductory book on Unix shells and shell programming.
      There are plenty of such books available, and you will save yourself
      a lot of trouble by having one handy and consulting it frequently.
      (Question 1.5 in the companion articles will let you know
       where you can find a list of good books.)

Please remember that the comp.unix.* newsgroups are read by over 80,000
people around the world, and that posting a question to this group will
cost a lot of time and money by the time your article is distributed to
Asia, Australia, Europe (west and east), Africa, the middle east,
all corners of North, South and Central America and even Antarctica.

Also, some people receive these newsgroups as part of a mailing list
rather than a newsgroup.  If you're one of these people, please don't
send a "Remove me from this list" or "UNSUBSCRIBE"  message to the
wrong place.  Take the time to figure out where you're getting this
stuff from, and send your request to the mailing list maintainer, *not*
to the list or newsgroup itself!  Ask your local postmaster for help.
(One of the answers in the companion articles deals with the details of
the mailing list.)

               To Which Newsgroup Should I Post My Question?

The choice of newsgroup is harder than it used to be.  In the old days,
you just had to choose between "comp.unix.questions" and
"comp.unix.wizards".  Now there are a variety of more specific groups.
This group, "comp.unix.shell" is only for questions relating to any of
the Unix shells and shell programing.  Other groups each have their own
mandates.

Choose one of the following groups carefully.  If you aren't sure where
your question belongs or if your question is not specific to some
particular version of Unix, try "comp.unix.questions".  Many
knowledgeable Unix wizards read that group and will be able to help you.

Here are the capsule descriptions of various groups you might consider
(extracted from a monthly posting to "news.announce.newusers")

comp.unix.shell         Using and programming any UNIX shell.

comp.unix.questions     General questions from UNIX users and sysadmins.
            If your question isn't a really good match for one of
            the groups below, post it here.

news.answers        Repository for periodic USENET articles. (Moderated)
            This article is crossposted there.
            Do not try to post here unless you're
            posting a list of FAQ's and their answers.

comp.lang.c             Discussion about C.

comp.sources.unix       Postings of complete, UNIX-oriented sources. (Moderated)
comp.std.unix           Discussion for the P1003 committee on UNIX. (Moderated)
comp.unix               Discussion of UNIX* features and bugs. (Moderated)
comp.unix.admin         Administering a Unix-based system.
comp.unix.aix           IBM's version of UNIX.
comp.unix.amiga        Unix on the Commodore Amiga
comp.unix.aux           The version of UNIX for Apple Macintosh II computers.
comp.unix.bsd           Discussions relating to BSD UNIX.
comp.unix.internals     Discussions on hacking UNIX internals.
comp.unix.large         UNIX on mainframes and in large networks.
comp.unix.misc          Various topics that don't fit other groups.
comp.unix.msdos         MS-DOS running under UNIX by whatever means.
comp.unix.programmer    Q&A for people programming under Unix.
comp.unix.sysv286       UNIX System V (not XENIX) on the '286.
comp.unix.sysv386       Versions of Unix (not Xenix) on Intel 80386-based boxes.
comp.unix.ultrix        Discussions about DEC's Ultrix.
comp.unix.xenix.misc    General discussions regarding XENIX (except SCO).
comp.unix.xenix.sco     XENIX versions from the Santa Cruz Operation.

comp.unix.wizards       In-depth discussions of advanced unix topics.
            People should not post to this group unless they
            have used unix as a user, sysadmin and know details
            of the kernel, and how different unix kernels differ.
            In other words, don't post to comp.unix.wizards.

          What Information Should I Include?

It's hard to include too much information.  There are hundreds of
different systems out there, and they all have less in common
than you might think.  If you have a problem and are posting an
article, please be sure to mention:

    o A descriptive subject line.  Many people will decide whether
      to read your article solely on the basis of the subject line,
      so it should be a good statement of your problem.

      NOT GOOD                          GOOD

      "Help"                            "How do I port csh scripts to ksh?"
      "Csh question"            "csh dumps core when I use '$<'"

    o What computer you are using, what specific version of the
      operating system it uses, and to what shell the question
      pertains.  For instance,

        SunOS 4.0.1, Sun 3/50, tcsh 6.00.03
        4.3BSD-tahoe, Vax 11/780, rc 1.0
        SVR3.2, 3b2, sh 4.2

    o If possible, the *exact* text of any error message you
      may have encountered.

      WRONG                RIGHT

      "My csh script doesn't run"    "When I type 'scriptname', I get
                      sh: scriptname: This isn't a shell script.
                      What does this mean?  It isn't in
                      the man page.  This is using crash 3.14
                      under Mueslix 9.3 on a Fax [phone]"

It's a good idea to post unrelated questions in separate articles,
so that people can keep different discussions separate.   It's also
a *very* good idea to include a line or two like this:

    "Please mail your answers to me and I'll summarize what I get
     and post the results to comp.unix.shell."

This prevents many identical responses from different users to the
same question from clogging up the newsgroup.  And make sure
you really summarize what you get - don't just concatenate
all the mail you've received.

It's also a good idea to read comp.unix.shell for at least a couple
of weeks after you post your article to see what followup articles
are posted.

                Should I Post an Answer to a Question?

It's very tempting to post an answer to a question you read on the net,
especially when you think "Aha, finally - a question I can answer!"
Consider though that when a simple question is asked, such as the
sort answered in the companion articles, many other people around the
world already know the answer and may be posting their own reply.
In order to avoid dozens of replies to simple questions, please
wait a day or so and see if anyone else has already answered
the question.  If you have something special to contribute, please
do so, but make sure you're not duplicating something someone else has
already done.

You should feel free to reply to any question >by email<.  Even if
the user gets 200 responses to his question, at least the load on the
rest of the net is minimized.

                    What About Posting Source Code?

Posting small amounts of example code is fine (use comp.sources.unix to
distribute complete programs) - but please make sure that your code
runs (or at least compiles) properly.  Don't just type it in while
editing your posting and hope it will work, no matter how sure you are
that it will.  We all make mistakes.

                        What About Those People
       Who Continue to Ask Stupid or Frequently Asked Questions
         In Spite of The Frequently Asked Questions Document?

Just send them a polite mail message, possibly referring them to this document.
There is no need to flame them on the net - it's busy enough as it is.
--
Ted Timar - [e-mail]
Empress Software, 3100 Steeles Ave E, Markham, Ont., Canada L3R 8T3
Xref: bloom-picayune.mit.edu comp.unix.questions:51328 news.answers:4769
Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!usenet
From: [e-mail] (Ted M A Timar)
Newsgroups: comp.unix.questions,news.answers
Subject: Changes to "Welcome to comp.unix.questions" [Frequent posting]
Supersedes: <unix-faq/unix/[e-mail]>
Followup-To: comp.unix.questions
Date: 24 Dec 1992 06:02:39 GMT
Organization: Empress Software
Lines: 29
Approved: [e-mail]
Distribution: world
Expires: 21 Jan 1993 06:02:09 GMT
Message-ID: <unix-faq/unix/[e-mail]>
NNTP-Posting-Host: pit-manager.mit.edu
X-Last-Updated: 1992/12/09

Archive-name: unix-faq/unix/diff

*** /tmp/,RCSt1a18541    Fri Dec  4 07:52:42 1992
--- intro    Fri Dec  4 07:42:48 1992
***************
*** 2,12 ****
  Newsgroups: comp.unix.questions,news.answers
  Followup-To: comp.unix.questions
  Organization: Empress Software
! Subject: Welcome to comp.unix.questions [Biweekly posting]
  Approved: [e-mail]

! Archive-name: unix-faq/unix-intro
! Version: $Id: intro,v 2.0 92/10/20 12:08:28 tmatimar Exp $

  Comp.unix.questions is one of the most popular and highest volume
  newsgroups on Usenet.  This article is a monthly attempt to remind
--- 2,12 ----
  Newsgroups: comp.unix.questions,news.answers
  Followup-To: comp.unix.questions
  Organization: Empress Software
! Subject: Welcome to comp.unix.questions [Frequent posting]
  Approved: [e-mail]

! Archive-name: unix-faq/unix/intro
! Version: $Id: intro,v 2.1 92/12/04 07:48:37 tmatimar Exp $

  Comp.unix.questions is one of the most popular and highest volume
  newsgroups on Usenet.  This article is a monthly attempt to remind
Xref: bloom-picayune.mit.edu comp.unix.questions:51330 news.answers:4772
Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!usenet
From: [e-mail] (Ted M A Timar)
Newsgroups: comp.unix.questions,news.answers
Subject: Welcome to comp.unix.questions [Frequent posting]
Supersedes: <unix-faq/unix/[e-mail]>
Followup-To: comp.unix.questions
Date: 24 Dec 1992 06:02:45 GMT
Organization: Empress Software
Lines: 199
Approved: [e-mail]
Distribution: world
Expires: 21 Jan 1993 06:02:09 GMT
Message-ID: <unix-faq/unix/[e-mail]>
NNTP-Posting-Host: pit-manager.mit.edu
X-Last-Updated: 1992/12/09

Archive-name: unix-faq/unix/intro
Version: $Id: intro,v 2.1 92/12/04 07:48:37 tmatimar Exp $

Comp.unix.questions is one of the most popular and highest volume
newsgroups on Usenet.  This article is a monthly attempt to remind
potential posters about what is appropriate for this newsgroup.
If you would like to make any suggestions about the content of
this article, please contact its maintainer at
[e-mail].

Companion articles include the answers to some Frequently
Asked Questions.  You may save yourself a lot of time by reading
those articles before posting a question to the net.